System for network device location

ABSTRACT

A management station responds to an HTTP request for device discovery by spawning a device discovery task that creates a linked list and first broadcasts UDP based requests out on a subnetwork for devices on the same subnetwork to respond. Device information from responding network devices is stored in a linked list. This process is repeated until a specified length of time has expired. Then a second broadcast request is sent out that includes a list of printers that have responded so that they will nor keep responding. The list is updated by responses until there are no more responses. Any nodes in the linked list that still only have a network address are updated by sending a unicast SNMP request those network addresses in order to get the additional information. The data from the linked list is sent back to the HTTP client.

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This applications is a divisional of co-pending U.S. applicationSer. No. 09/199,935, filed Nov. 25, 1998, the contents of which areincorporated herein by reference.

BACKGROUND OF THE INVENTION

[0002] The present invention relates to locating devices on a network,and more particularly to allowing a network device to locate othernetwork devices on the same sub-network.

[0003] Some users of devices residing on a network find it desirable tolocate all or a class of other devices on the network. For example, auser may wish to have a list of all the printers of a certain brand,along with information about those printers that are on the samesub-network. Typically, a network device would perform such a searchusing a network communications method (protocol) such as Simple NetworkManagement Protocol (SNMP).

[0004] A network device typically searches for other devices on thenetwork by sending (User Datagram Protocol) UDP messages to thesub-network and then waiting for particular responses from networkdevices that are listening on the same sub-network. The network devicethat sends out the request is typically called a management station anda device responding to such a request is typically referred to as anetwork agent.

[0005] UDP is a protocol that offers a limited amount of service whenmessages are exchanged between network devices in a network that usesthe Internet Protocol (IP). A persistent problem is the loss ofinformation packets due to congestion in the network or the receivingdevice, whether a management station or agent. Congestion essentially isthe existence of interfering messages. One way this problem can occur,for example, is when responses from network agents arrive as a result ofthe UDP broadcast message from the management station and they areinitially received by the on-board Ethernet driver. This driver executesat a high priority intercepting every packet that arrives. If the packethas the expected frame type then the packet is ready to be delivered tothe IP layer of the network stack. The IP task, which is running at alower priority than the Ethernet driver, needs to accept as many packetsas possible from the Ethernet driver. The total buffer area for the IPtask is finite and the buffer for the Ethernet driver is also finite.Available buffer space depends on how fast the application task that isexecuting UDP routines can read and consume the data. Since both the 1Ptask and the UDP level task run at a lower priority than the EthernetDriver and total buffer space of the Ethernet driver is limited, themanagement station will not be able to read all the UDP based responsepackets that arrive at the on-board Ethernet driver. This approach ofusing UDP alone prevents an exhaustive and reliable search of thenetwork since some request or response packets can be lost.

[0006] Service Location Protocol (SLP), described in the InternetRequest For Comments document 2165 (RFC 2165), is one protocol that maybe used instead of, or to supplement UDP based SNMP broadcast andresponses. SLP provides a means to send in the broadcast request a listof devices that have already responded such that those who have alreadyresponded will not do so again. However, using SLP would result inslower and more cumbersome location of devices on the network because ofits complexity and lack of specialization.

[0007] A second problem also exists when attempting to locate or finddevices with no IP address. Prior approaches using IP multicastingrequire registration with the router and therefore do not provide acomplete solution.

[0008] What is desired is a system for network device location thatprovides a faster and more exhaustive search which supplements the basicUDP broadcast and responses in order to reliably receive responsepackets from network agents or devices, and to uniquely identify thosedevices without relying on their IP address.

SUMMARY OF THE INVENTION

[0009] Accordingly, the present invention provides a faster, moreexhaustive search and supplements the basic UDP broadcast and responsesin order to receive and read more response packets from network agents.The present invention provides an approach to achieve device locationdiscovery based on a MAC (media access channel) address even though theIP address is not known.

[0010] The invention employs a unicast (HTTP) request that is sent on anetwork to a device, such as a printer, with a known location and thatdevice discovers other devices with unknown network locations. Thedevice with the known location returns a web page to the user showingits status, with links to the other discovered devices. The user canthen select the link to one of the newly discovered devices and view theweb page of the selected device.

[0011] A device implementing this invention responds to an HTTP requestfor device discovery by spawning a device discovery task that broadcastsa SNMP over UDP based request out on a subnetwork for devices torespond. When responses are received they are parsed and the deviceinformation such as network address, name, status, version and model isadded to a list of discovered devices. Any responses from devicesoutside a specified class of devices, such as those not of a certainbrand, are disregarded. The task waits for the responses until aspecified amount of time has expired.

[0012] Then a device location protocol (DLP) over UDP broadcast requestis sent out that includes a list of devices, such as printers, that haveresponded. The request is that only devices not on the list respond.Responses are then parsed and the responding device's network address isadded to the list of responding devices. This process is repeated untilthere are no more responses.

[0013] The management station may use unicast SNMP requests to thedevices in the list to learn additional information about those deviceswhich have an assigned IP address. The data from the linked list is thencopied into a (Hypertext Markup Language) HTML buffer to be sent to theHTTP client that sent the original request.

[0014] These aspects, advantages, and other novel features of thepresent invention are apparent from the following detailed descriptionwhen read in conjunction with the appended claims and attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015]FIG. 1 is a block diagram representing various servers and clientson a network that are involved in network device location according tothe present invention.

[0016]FIG. 2 is a flow chart of the process of network device locationaccording to the present invention.

[0017]FIG. 3 is a diagram of a device location protocol (DLP) requestpacket according to the present invention.

[0018]FIG. 4 is a diagram of a device location protocol (DLP) responsepacket according to the present invention.

[0019]FIG. 5A is a diagrammatic illustration of a device locationprotocol (DLP) wherein a device (printer) with a known locationbroadcasts a request and discovers the locations of other unknowndevices while permitting the user to select and view the web page of adiscovered device.

[0020]FIG. 5B is a diagrammatic illustration of another device locationprotocol (DLP) wherein a device (personal computer) broadcasts a requestand discovers the locations of unknown devices and assigns an IP addressto those discovered devices.

[0021]FIG. 6 is a sample of the web page viewed by the user in FIG. 5.

[0022]FIG. 7 is a list of locations of other devices linked to the knowndevice in FIG. 5.

DESCRIPTION OF THE PREFERRED EMBODIMENT

[0023] Referring to FIG. 1, various network devices 35 such as printersreside on a network 45. A user on the network with a Hypertext TransferProtocol (HTTP) client 15, or web browser, wishes to find either alldevices that reside on the network 45, or those of a specified class,such as a certain brand of printers, and obtain information about thosedevices. The HTTP client 15 sends an HTTP request to a managementstation 5, which has an HTTP server running in order to find desirednetwork devices. This request is called a device discovery request.

[0024] Referring to FIG. 2, the HTTP server waits for HTTP requests 50.After receiving the device discovery request 55, the HTTP server spawnsa device discovery task 10 as shown in FIG. 1. The HTTP server ispreferably designed to spawn up to five device discovery tasks, each ofwhich can run concurrently. The priority level of the device discoverytask 10 is the same as the priority level of the HTTP server task in themanagement station 5. This priority level will enable the devicediscovery task to read as much data as possible from the InternetProtocol (IP) task in the management station 5, and at the same time itwill not starve the HTTP server from the processor (CPU) time slice.

[0025] Referring to FIG. 2, after the device discovery task initializes60 (allocates memory, initialize semaphores, etc.), it creates a datastructure to store device information 65. In the preferred embodiment,this is a linked list, but may be any other data structure that providessimilar features. A node is added to the list 65 for a local device 40,such as that as shown in FIG. 1, and the device name, model and statusare copied into the node 65.

[0026] The device discovery task 10 is a subset of a typical SNMPManager, sending SNMP request UDP broadcast packets 70 to all the SNMPAgents 35 who are listening in the same sub-network. These broadcastpackets contain a broadcast destination IP address, have a destinationport as 161, and are received by any application listening on port 161on any active node. While the SNMP agents 35 respond to this requestbroadcast 70, the device discovery task waits 75 for a configured amountof time (TIMEOUT) for all the responses to arrive. The device discoverytask 10 uses parsing functions provided by the NEST SNMP library togenerate SNMP requests and also to parse the responses from the SNMPAgents 35. The SNMP response packets are parsed with the NEST SNMPlibrary routines in order to extract the object identification and valuepair. These values that are extracted from the NEST internal datastructure contain information about the device name, model, and status,hereafter called SNMP information.

[0027] In the preferred embodiment, the responder's IP address and SNMPinformation is extracted from these response packets and saved into alinked list 90 only if the packets are from devices in a desired classof devices 85, 80, such as printers of a certain brand, but this stepmay be skipped without going beyond the scope of this invention. Whenthis step is skipped, any devices residing on the same sub-network thatare SNMP Agents 35 could be located. If the response packets are notfrom devices of the desired class, the packet is simply discarded by thedevice discovery task 80.

[0028] After the expiration of TIMEOUT seconds 95, the device discoverytask 10 sends a UDP based broadcast request 100 according to theprotocol in FIG. 3, hereafter called (device location protocol) DLP. TheDLP broadcast request operates on port 1200 and contains a request forany devices listening 35 that are not already a member of the linkedlist, to respond. Referring to FIG. 3, the request packet contains theIP addresses of devices that have already responded, such that thedevices with a DLP server running will know not to respond if their IPaddress appears in the list. The length of each IP address is includedbefore each IP address in the request. This is an important improvementover SLP because indicating the length of the IP address before eachaddress, as opposed to merely separating the addresses by a semicolon(see RFC 2165), DLP servers 35 do not have to parse every byte of therequest, which results in faster searches. This is because the DLPserver within the network devices 35 will know the length of eachaddress beforehand.

[0029] Only DLP servers 35 listening on port 1200 respond to thisrequest. Referring to FIG. 3, the DLP server will reject the requestmessage if any of the following conditions are true:

[0030] 1) Length of the request buffer is less than 9 bytes. As shown inFIG. 3, the first 8 bytes of the request buffer are for version number(4 bytes) and length of the whole packet (4 bytes). The next 1 byte isallocated for section of the request packet and for indicating the modelname. This is a total of at least 9 bytes for the request message.

[0031] 2) If value in the length section of the request buffer is notequal to the total number of bytes returned in the UDP packet.

[0032] 3) If the value of the IP address length is more than thecalculated value of the bytes following the position of the IP addresslength field.

[0033] 4) If any of the values of IP address length field is zero orless than zero.

[0034] Whenever the device discovery task 10 receives a DLP response105, 102, responder's IP address is added to the list 110, only if thatIP address is not already found in the list. The DLP response protocolappears in FIG. 4. Note that the response includes the currentresponder's machine address (MAC address) as well as the IP address.This is also an important improvement over SLP because new devices maynot have an IP address, but will be able to be detected anyway.

[0035] Referring to FIG. 4, the device discovery task 10 will reject theresponse if any of the following conditions are true:

[0036] 1) length of the response buffer is less than 10 bytes (4 bytesfor version number, 4 bytes for the length of buffer, 1 byte for devicemodel name, and 1 byte for device IP Address).

[0037] 2) If the value of IP Address length field is zero or less.

[0038] 3) If the length of the buffer is not equal to the total bytereturn by the recvfrom socket call.

[0039] 4) If the value of the IP Address length is more than thecalculated value of the bytes following the position of the IP Addresslength field.

[0040] 5) If the MAC address is less than or equal to zero.

[0041] 6) If the value of the MAC Address length is more than thecalculated value of the bytes following the position of the MAC Addresslength field.

[0042] If at least one response has arrived after the last and mostrecent DLP request broadcast, another DLP request is generated 102, 100.Otherwise, if no request has arrived after the last and most recent DLPrequest broadcast the device discovery task 10 closes the DLP port andgenerates a SNMP request unicast to each of those IP address in thelinked list that were added to the list as result of DLP responses 115.These SNMP request messages to each of the IP addresses are unicastmessages generated to a maximum set of 10 destinations at a time. Afterup to a maximum of 10 unicast requests are generated, the devicediscovery task 10 waits again 120 up to TIMEOUT seconds for the SNMPresponse packets to arrive. When they arrive, the SNMP information suchas device name, model, version number, and device status are copied intothe list 125.

[0043] This continuous sequence of generating up to 10 SNMP requestunicast messages and waiting up to TIMEOUT for the SNMP response packetsto arrive and then copying the SNMP information to the list comes to anend when all the remaining IP addresses from the linked list areexhausted 130. The device discovery task 10 then generates the HypertextMarkup Language (HTML) based buffer 135 from the information collectedin the linked list. The HTTP server running on the management station 5is partially single threaded and this single threaded portion is locatedin the area where the server prepares the HTML buffer to be sent to theHTTP client 15. The device discovery task 10 and other servers may sharea semaphore with the HTTP server task, and as a result only one task ata time can prepare and send the HTML buffer back to the HTTP client.Therefore, the device discovery task 10 locks a semaphore 140, and thensends the HTML packet with the generated table of located deviceinformation to the HTTP client 15. The device discovery task thenunlocks the semaphore 150, frees the list 150 and exits 155.

[0044] The approach shown in FIG. 5A has a web client PC 11 send out anHTTP request on a network to a printer 12 with a known location and thatdevice acts as a management station to discover other printers 13 and 14with unknown network locations. The printer 12 with the known locationreturns a web page in the form of a formatted HTML page to the usershowing its status, with links to the other discovered printers 13 and14. The user can then select the link to one of the newly discoveredprinters and view the web page of the selected printer. A newlydiscovered printer 13 can repeat the process to discover other devices12 and 14, or newly added devices to the network (not shown). FIG. 6shows a representative web page for a printer, while FIG. 7 shows apartial listing of printers in a network with the printer name, modelnumber, IP name and status.

[0045] In an alternative approach seen in FIG. 5B, PC 11 sends out abroadcast request to all devices on the network. DLP capable devices 12,13, and 14 individually send DLP replies to PC 11 which containinformation (model and serial number) needed to identify the deviceseven though the devices do not have an IP address. PC 11 selects an IPaddress using an algorithm, such as Microsoft's Automatic Private IPNetwork Addressing employed in Windows 98. The PC 11 uses Dynamic HostConfiguration Protocol (DHCP) to assign the IP address to the networkdevice. PC 11 can repeat the process until all devices are identifiedand assigned an IP address.

[0046] Thus, the present invention provides a more exhaustive search andsupplements the the UDP based SNMP broadcast and responses in order toreceive and read more response packets from network agents.

[0047] Accordingly, the spirit and broad scope of the appended claims isintended to embrace all such changes, modifications and variations thatmay occur to one of skill in the art upon a reading of the disclosure.All patent applications, patents and other publications cited herein areincorporated by reference in their entirety.

What is claimed is:
 1. A method of network device location, comprising:sending a DLP request to devices on the network; receiving DLP responsesfrom responding devices on the network, wherein the DLP responseincludes information uniquely identifying the device; generating a listof responding devices; assigning an IP address to each responding devicenot having an IP address; sending the IP address to the respondingdevices; and updating the list of responding devices to include theassigned IP address.
 2. The method of claim 1, wherein the DLP responsesfrom the devices include at least a MAC address.
 3. A system forlocating devices on a network, comprising: at least one device having aDLP server for sending DLP responses, wherein a DLP response includesinformation uniquely identifying the device; and a first device having aDLP client for sending a DLP request to devices on the network; forreceiving DLP responses from responding devices; for generating a listof responding devices; for assigning an IP address to each respondingdevice not having an IP address; and for sending the IP address to theresponding devices; and for updating the list of responding devices toinclude the assigned IP address.
 4. The system of claim 3, wherein theDLP response includes a MAC address.
 5. The system of claim 3, whereinthe first device comprises a computer and the at least one devicecomprises a printer.